[ANNOUNCE] mod_perl 2.0.5

mod_perl 2.0.5 is here!

Thanks to the many, many contributors to this version. Please see the
summary of changes below, along with a special dedication for this
release to Randy Kobes.

You can get mod_perl 2.0.5 at one of the following urls, including the CPAN:

http://perl.apache.org/download/index.html

http://apache.org/dist/perl/mod_perl-2.0.5.tar.gz
http://apache.org/dist/perl/mod_perl-2.0.5.tar.gz.asc (pgp sig)

md5: 03d01d135a122bd8cebd0cd5b185d674

---------------------------------------------------

The mod_perl PMC dedicates this release of mod_perl to Randy Kobes, who
passed away in September 2010. Randy was a member of the mod_perl project
management committee and a co-author of the mod_perl Developer's Cookbook.
His work helped many Windows mod_perl users. His work with ppm files, and
Win32 perl users will be sorely missed. He was kind, bright, and always
willing to lend a hand on the mod_perl user's list.

Prepare modperl for the upcoming perl 5.14 [Torsten Foertsch]

Add lib/ModPerl/MethodLookup.pm to MANIFEST via lib/ModPerl/Manifest.pm
RT #48103 reported by MARKLE@cpan.org
[Fred Moyer]

PerlIOApache_write() now throws an APR::Error object, rather than just a string
error, if modperl_wbucket_write() fails.
[Steve Hay]

Authentication tests fail with LWP 5.815 and later
[Doug Schrag]

Concise test won't perform unless StatusTerse is set to ON
[Doug Schrag]

Look for a usable apxs in $ENV{PATH} if all other options fail, then
prompt the user for one.
[Phred]

Work around bootstrap warnings when Apache2::BuildConfig has not been
created yet.
[Phred]

Remove Apache::test compatibility (part of mod_perl 1.2.7), that code
causes build issues and is 4 versions out of date.
[Phred]

Make sure perl is built either with multiplicity and ithreads or without
both [Theory, Torsten]

Support for "install_vendor" and "install_site" make targets [Torsten]

Run tests on bundled pure perl Apache::* modules [Gozer, Phred]

Implement a mini-preprocess language for map-files in xs/maps.
[Torsten Foertsch]

Implement APR::Socket::fileno [Torsten Foertsch]

Export PROXYREQ_RESPONSE, a missing PROXYREQ_* constant [Gozer]

Make sure standard file descriptors are preserved by the perl-script
handler [Torsten Foertsch]

Fix the filter init handler attribute check in
modperl_filter_resolve_init_handler() [Torsten Foertsch]

Make sure buffer is a valid SV in modperl_filter_read() [Torsten Foertsch]

Move modperl_response_finish() out of modperl_response_handler_run in
mod_perl.c [Torsten Foertsch]

"MODPERL_INC= now correctly supported as an argument to Makefile.PL"
[Torsten Foertsch]

Fix an XSS issue in Apache2::Status reported by Richard J. Brain
. [Torsten Foertsch]

Add NOTICE file to the distribution. [Joe Schaefer]

Make sure Apache2::RequestIO::read doesn't clear the buffer on end of
file and handle negative offsets and offsets that are larger than
the current string length. [Torsten Foertsch]

Fix a problem that could make APR::XSLoader and Apache2::XSLoader
load the wrong shared library. [Torsten Foertsch]

Fix compilation when using a non-threaded APR.
[Gozer, Philip M. Gollucci]

Make sure mod_perl's own ChildInitHandlers are run before user
supplied ones. This fixes the incorrectly reported value of $$
at ChildInit time [Gozer]

Re: [ANNOUNCE] mod_perl 2.0.5

Many thanks guys, for keeping mod_perl alive and well (and perl too for that matter).
It is really a pity that not more people know how much their nice web applications depend
on it.
But then, maybe we should think that the people who matter, do know.

Re: [ANNOUNCE] mod_perl 2.0.5

On Mon, 2011-02-07 at 17:55 -0800, Fred Moyer wrote:
> mod_perl 2.0.5 is here!

Well done! and thanks

clint

Re: [ANNOUNCE] mod_perl 2.0.5

On Tue, Feb 8, 2011 at 4:10 AM, Clinton Gormley wrot=
e:
> On Mon, 2011-02-07 at 17:55 -0800, Fred Moyer wrote:
>> mod_perl 2.0.5 is here!
>
> Well done! =A0and thanks

Thanks to the users who took the time to try out release candidates,
fix and report bugs.

Saw this today - word is getting out about the release:

http://techfeed.ru/2011/02/vyshel-modperl-2-0-5/

Re: [ANNOUNCE] mod_perl 2.0.5

Thank you so much for the new release!

Jie

Please think of our environment and only print this e-mail if necessary.

* Andr? Warnier wrote:

> Date: Tue, 08 Feb 2011 09:18:33 +0100
> From: Andr? Warnier
> To: mod_perl Dev
> CC: mod_perl list
> Subject: Re: [ANNOUNCE] mod_perl 2.0.5
> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
>
> Many thanks guys, for keeping mod_perl alive and well (and perl too for that matter).
> It is really a pity that not more people know how much their nice
> web applications depend on it.
> But then, maybe we should think that the people who matter, do know.
>

Re: [ANNOUNCE] mod_perl 2.0.5

--90e6ba53a054ba6c48049be421b4
Content-Type: text/plain; charset=UTF-8

Awesome everyone. Thanks for working on the new release of mod_perl. I look
forward to implementing it.

Has anyone tried 2.0.5 on Windows?


On Wed, Feb 9, 2011 at 6:12 PM, Jie wrote:

> Thank you so much for the new release!
>
> Jie
>
> Please think of our environment and only print this e-mail if necessary.
>
> * Andr? Warnier wrote:
>
> > Date: Tue, 08 Feb 2011 09:18:33 +0100
> > From: Andr? Warnier
> > To: mod_perl Dev
> > CC: mod_perl list
> > Subject: Re: [ANNOUNCE] mod_perl 2.0.5
> > User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
> >
> > Many thanks guys, for keeping mod_perl alive and well (and perl too for
> that matter).
> > It is really a pity that not more people know how much their nice
> > web applications depend on it.
> > But then, maybe we should think that the people who matter, do know.
> >
>

--90e6ba53a054ba6c48049be421b4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Re: [ANNOUNCE] mod_perl 2.0.5

> Awesome everyone. Thanks for working on the new release of mod_perl. I look
> forward to implementing it.

This is great news! I'm very pleased to see this update because it
flies in the face of those who incorrectly insist that ModPerl is
dead because it hasn't been updated for a long time -- I've been
pointing out that the lack of updates are due to better quality code
and fewer change requirements.

Thanks too all developers and contributors of ModPerl! I've been
hooked on this technology ever since I started using it, and I enjoy
the high performance and deep integration into APR and HTTPd.

> Has anyone tried 2.0.5 on Windows?

I haven't yet, but I look forward to trying it on NetBSD 5.1. I am
interested in trying it on Windows when a binary is available...

I find that running ModPerl on Windows generally works well until
Perl scripts are changed frequently (and using the Reload module),
and then Apache HTTPd will either stop responding or just crash out
(especially if PerlMagick is in the mix). I wonder if this might be
an OS-specific problem thought since my Unix servers just don't
exhibit these symptoms.

[End of reply.]

> On Wed, Feb 9, 2011 at 6:12 PM, Jie wrote:
>
> > Thank you so much for the new release!
> >
> > Jie
> >
> > Please think of our environment and only print this e-mail if necessary.
> >
> > * Andr? Warnier wrote:
> >
> > > Date: Tue, 08 Feb 2011 09:18:33 +0100
> > > From: Andr? Warnier
> > > To: mod_perl Dev
> > > CC: mod_perl list
> > > Subject: Re: [ANNOUNCE] mod_perl 2.0.5
> > > User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
> > >
> > > Many thanks guys, for keeping mod_perl alive and well (and perl too for
> > that matter).
> > > It is really a pity that not more people know how much their nice
> > > web applications depend on it.
> > > But then, maybe we should think that the people who matter, do know.
> > >
> >
>


Randolf Richardson - randolf@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
http://www.inter-corporate.com

Re: [ANNOUNCE] mod_perl 2.0.5

* Randolf Richardson wrote:

> Date: Wed, 09 Feb 2011 19:22:06 -0800
> From: Randolf Richardson
> To: mod_perl Dev ,
> mod_perl list
> Subject: Re: [ANNOUNCE] mod_perl 2.0.5
> X-mailer: Pegasus Mail for Windows (4.52)
>
> > Awesome everyone. Thanks for working on the new release of mod_perl. I look
> > forward to implementing it.
>
> This is great news! I'm very pleased to see this update because it
> flies in the face of those who incorrectly insist that ModPerl is
> dead because it hasn't been updated for a long time -- I've been
> pointing out that the lack of updates are due to better quality code
> and fewer change requirements.
>
> Thanks too all developers and contributors of ModPerl! I've been
> hooked on this technology ever since I started using it, and I enjoy
> the high performance and deep integration into APR and HTTPd.

I totally agree!

The quality design and code by Doug MacEachern laid the foundation. And
thanks to Stas Bekman for the 2.0!


-Jie

Re: [ANNOUNCE] mod_perl 2.0.5

> Has anyone tried 2.0.5 on Windows?

Yes I have compiled it with VC2010 and Activestate Perl 5.10.1 Build 1007.
It works fine I have worked with it for a couple of days now.
I have tested with Windows XP, Windows 7 and Windows 2003 all working fine.

> I find that running ModPerl on Windows generally works well until
> Perl scripts are changed frequently (and using the Reload module),
> and then Apache HTTPd will either stop responding or just crash out
> (especially if PerlMagick is in the mix). I wonder if this might be
> an OS-specific problem thought since my Unix servers just don't
> exhibit these symptoms.

I use reload all the time it worked OK for most modules but some modules
(at least the ones that use "use base 'modulename';" ) will have problems.
The good thing is that on Windows 7-64bit and 2008R2-64bit, the start and
stop of apache is much faster then on the old 32 bit systems (Win2003, XP)

---
Thomas den Braber

"use base" and mod_perl

Hi Thomas,

On Fri, 2011-02-11 at 12:50 +0100, Thomas den Braber wrote:

> I use reload all the time it worked OK for most modules but some modules
> (at least the ones that use "use base 'modulename';" ) will have problems.

Do you have any idea why this is?
Actually I ran into this issue as well; see
http://bugs.otrs.org/show_bug.cgi?id=6218#c4

but I also had these reports coming from mod_perl on Debian.

--
Mike

Re: [ANNOUNCE] mod_perl 2.0.5

[sNip]
> > I find that running ModPerl on Windows generally works well until
> > Perl scripts are changed frequently (and using the Reload module),
> > and then Apache HTTPd will either stop responding or just crash out
> > (especially if PerlMagick is in the mix). I wonder if this might be
> > an OS-specific problem thought since my Unix servers just don't
> > exhibit these symptoms.
>
> I use reload all the time it worked OK for most modules but some modules
> (at least the ones that use "use base 'modulename';" ) will have problems.

That's very interesting because where I'm seeing the crashing
usually involves code that uses "use base" somewhere (in one
particular case the base is for some basic database stuff that
utilizes "DBIx::Class"-auto-generated code).

The only other times I can recall where I've experienced this
crashing is with the Apache2::Upload module, or with the
Image::Magick (PerlMagick) module (there are only a few instances
where I'm not using these two together). Even for test scripts where
I don't use "use base" at all, I can still get crashing with
Apache2::Reload after many script file changes, so I wonder if
Apache2::Upload depends on something that uses "use base" somewhere,
or if there's something common that it depends on that "use base"
also depends on? If so, then perhaps this points to the problem.

I know that Image::Magick is a problem child in many ways, so I
suspect this could just be the same symptom with a different cause.

> The good thing is that on Windows 7-64bit and 2008R2-64bit, the start and
> stop of apache is much faster then on the old 32 bit systems (Win2003, XP)

I find that 64-bit Windows 7 is faster at this too. Additionally,
Windows 7 (and I recall also Vista) has a new "Delayed start" option
for the Services which is nice for starting Apache HTTPd later on
test boxen.

Randolf Richardson - randolf@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
http://www.inter-corporate.com

Re: [ANNOUNCE] mod_perl 2.0.5

On 02/11/2011 12:02 PM, Randolf Richardson wrote:

>> I use reload all the time it worked OK for most modules but some modules
>> (at least the ones that use "use base 'modulename';" ) will have problems.
>
> That's very interesting because where I'm seeing the crashing
> usually involves code that uses "use base" somewhere (in one
> particular case the base is for some basic database stuff that
> utilizes "DBIx::Class"-auto-generated code).

I highly doubt that it's tied to "use base" at all, but instead is
caused by modules that are highly dynamic (do things like create methods
at runtime like DBIx::Class would do). But because this magic is buried
in the base class you don't see it until you use that base class as your
parent (via "use base").

Perl doesn't have a real way to unload a module or to completely force a
reload. Apache::Reload tries it's best but there are lots of modules it
can't handle. It's not it's fault really, it's a feature that's missing
in Perl.

These days, I never use Apache::Reload. I just restart my dev server (
yes, I believe each dev should have their own dev Apache server).

--
Michael Peters
Plus Three, LP

Re: [ANNOUNCE] mod_perl 2.0.5

> On 02/11/2011 12:02 PM, Randolf Richardson wrote:
>
> >> I use reload all the time it worked OK for most modules but some modules
> >> (at least the ones that use "use base 'modulename';" ) will have problems.
> >
> > That's very interesting because where I'm seeing the crashing
> > usually involves code that uses "use base" somewhere (in one
> > particular case the base is for some basic database stuff that
> > utilizes "DBIx::Class"-auto-generated code).
>
> I highly doubt that it's tied to "use base" at all, but instead is
> caused by modules that are highly dynamic (do things like create methods
> at runtime like DBIx::Class would do). But because this magic is buried
> in the base class you don't see it until you use that base class as your
> parent (via "use base").

Using any base class seems to be a common denominator when I'm
experiencing these problems. It doesn't matter if DBIx::Class is in
the picture or not either (there are also many scripts that don't
interact with any databases).

This is only happening to me on Windows though too, and just hasn't
been a problem under NetBSD running the same versions of Apache
HTTPd, APR, and Perl (although on the Windows side we're using
ActivePerl so perhaps that's a better culprit since NetBSD is using
Perl from pkgsrc?) with the same scripts.

> Perl doesn't have a real way to unload a module or to completely force a
> reload. Apache::Reload tries it's best but there are lots of modules it
> can't handle. It's not it's fault really, it's a feature that's missing
> in Perl.

That's helpful information. At least on Unix I find that
Apache2::Reload seems to be doing a good job of making this happen.

Since I don't use Windows as production servers, this is mostly just
an annoyance, but it would be nice to figure it out eventually. =)

> These days, I never use Apache::Reload. I just restart my dev server (
> yes, I believe each dev should have their own dev Apache server).

On Unix, I just restart as well since it's so quick, but on Windows
I find that restarting is still slow (even on 64-bit Windows 7 which
does this much faster than Windows XP) so I'll use Apache2::Reload
for the first few times before restarting HTTPd -- usually the first
few times don't result in any problems, and sometimes I can get away
with 5 or 6 reloads before having to restart the HTTPd service.

I agree that each developer should have their own server to crash
and burn. I also like the idea of a pre-production "test"
environment that is just like production since developer machines can
often have extra libraries installed that don't exist on the
production servers (that usually isn't as fun as people claim!).

Randolf Richardson - randolf@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
http://www.inter-corporate.com

Re: "use base" and mod_perl

Mike,

> Do you have any idea why this is?
> Actually I ran into this issue as well; see
> http://bugs.otrs.org/show_bug.cgi?id=6218#c4
>

I haven't figured out what causes the problem but have found that if you add:

$ModPerl::Util::DEFAULT_UNLOAD_METHOD = 'unload_package_xs';

To my startup.pl file, reload works for the "use base 'modulename';"
modules but not always for other modules.

What I do is enable/disable this option depending on the module I am
working on.

Very important that you do not enable the reload option for production
servers. So it is only some extra trouble in development and restarting
your development server every now and then is not a problem.

--
Thomas den Braber

Re: [ANNOUNCE] mod_perl 2.0.5

> The only other times I can recall where I've experienced this
> crashing is with the Apache2::Upload module, or with the
> Image::Magick (PerlMagick) module (there are only a few instances
> where I'm not using these two together). Even for test scripts where
> I don't use "use base" at all, I can still get crashing with
> Apache2::Reload after many script file changes, so I wonder if
> Apache2::Upload depends on something that uses "use base" somewhere,
> or if there's something common that it depends on that "use base"
> also depends on? If so, then perhaps this points to the problem.

I use PerlMagick and Apache2::Upload also. I never had problems with them.
I use: PerlSetVar ReloadDirectories "/my_dev_dir" to only monitor my own
modules and not any of the others (Apache2, PerlMagick, etc.).
That causes less overhead (only about 10 ms per request for my ~60
modules) and maybe prevent other strange behaviour.

--
Thomas den Braber

Re: [ANNOUNCE] mod_perl 2.0.5

> This is only happening to me on Windows though too, and just hasn't
> been a problem under NetBSD running the same versions of Apache
> HTTPd, APR, and Perl (although on the Windows side we're using
> ActivePerl so perhaps that's a better culprit since NetBSD is using
> Perl from pkgsrc?) with the same scripts.
>

On linux I also had never any problem with Reload. But on Linux I always
run Apache with prefork MPM (I have not tested with Worker MPM on Linux
yet), on Windows there is only Worker MPM, can there be a relation between
the reload problem and the Worker MPM?

---
Thomas den Braber

Re: [ANNOUNCE] mod_perl 2.0.5

On Sat, Feb 12, 2011 at 3:26 PM, Thomas den Braber wrote:
> On linux I also had never any problem with Reload. But on Linux I always
> run Apache with prefork MPM (I have not tested with Worker MPM on Linux
> yet), on Windows there is only Worker MPM, can there be a relation between
> the reload problem and the Worker MPM?

Not likely. Threads don't share any data in Perl unless you tell them
to. The things Reload has trouble with tend to be sneaky programming
tricks, like auto-generated methods and classes.

- Perrin

Re: [ANNOUNCE] mod_perl 2.0.5 (and DBIx::Class auto-generated code)

> On Sat, Feb 12, 2011 at 3:26 PM, Thomas den Braber wrote:
>
> > On linux I also had never any problem with Reload. But on Linux I always
> > run Apache with prefork MPM (I have not tested with Worker MPM on Linux
> > yet), on Windows there is only Worker MPM, can there be a relation between
> > the reload problem and the Worker MPM?
>
> Not likely. Threads don't share any data in Perl unless you tell them
> to. The things Reload has trouble with tend to be sneaky programming
> tricks, like auto-generated methods and classes.

I never use the auto-generation feature in DBIx::Class from the web-
server side -- I always generate these from a shell prompt first and
then install them.

I know there are a lot of people using DBIx::Class with auto-
generation, probably because it's easier, but if something changes in
the database then the class will change which could lead to some
developers wondering what went wrong.

It's interesting to know that auto-generated code is a problem, and
this is providing me with some insight into why some DBIx::Class
users have been telling me that mod_perl (all versions) is so
terrible (I didn't experience the problems they described, and your
comment has shed some light on a possible reason).

Thanks!

Randolf Richardson - randolf@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
http://www.inter-corporate.com

Re: [ANNOUNCE] mod_perl 2.0.5 (and DBIx::Class auto-generated code)

On Sat, Feb 19, 2011 at 1:30 PM, Randolf Richardson wr=
ote:
> =A0 =A0 =A0 =A0It's interesting to know that auto-generated code is a pro=
blem, and
> this is providing me with some insight into why some DBIx::Class
> users have been telling me that mod_perl (all versions) is so
> terrible (I didn't experience the problems they described, and your
> comment has shed some light on a possible reason).

For what it is worth, I've been using DBIx::Class with mod_perl for
over five years now, and have not run into any problems worth
mentioning. I separate my model code from my request handlers though,
and increment the dependency version in my Makefile.PL, so I do a
server restart whenever I update one of the dependent modules. The
code separation causes the development process to take more time, but
the code is usually better quality in my opinion.

I build a model library with DBIx::Class autoloaders, to which I add
custom methods for my model classes. Takes a lot of the book keeping
work out of making accessor methods, etc.

Re: [ANNOUNCE] mod_perl 2.0.5 (and DBIx::Class auto-generated code)

On Sat, Feb 19, 2011 at 4:30 PM, Randolf Richardson wr=
ote:
> =A0 =A0 =A0 =A0It's interesting to know that auto-generated code is a pro=
blem, and
> this is providing me with some insight into why some DBIx::Class
> users have been telling me that mod_perl (all versions) is so
> terrible (I didn't experience the problems they described, and your
> comment has shed some light on a possible reason).

The sort of trouble I've seen with auto-generated code has to do with
changing subs in ways that perl is unable to deal with without
restarting the interpreter. For example, if you define a constant
(which is a sub with a prototype in perl), and then change it and try
to reload the module, you will have trouble. If you change the
inheritance of a class, you may also have trouble.

These things would be exactly the same under FastCGI or any other Perl
environment. The problem is that Perl can't really reload classes on
the fly, and tools that try to do it are simply deleting things from
the symbol table and loading the code again. Sometimes this works and
sometimes it doesn't, and the trickier your code is, the more likely
it is to not work.

Take people's prejudices against mod_perl with a grain of salt. There
are many misconceptions out there about mod_perl, but when you run it
in the recommended configuration (with a proxy server in front) there
is very little real difference from FastCGI and friends.

- Perrin

Re: [ANNOUNCE] mod_perl 2.0.5

--90e6ba4fc18cb6550204a4660fe7
Content-Type: text/plain; charset=UTF-8

I have finally started testing mod_perl-2.0.5 on windows (both win 2003 /
2008).

I compiled mod_perl using Visual Studio 2010 Express, Perl 5.10.1, and
Apache 2.2.19.

The reason that I wanted to use 2.0.5 of mod_perl was to resolve the issue
with the Apache Process stopping. This was the original issue that I was
able to repeat with 2.0.4 -
http://www.gossamer-threads.com/lists/modperl/dev/102357

From my testing, I still can stop the Apache process by stopping the browser
in a middle of a connection.

I used to have APR does not understand... Now, I have this error (instead of
the APR error):

ModPerl::Util::exit: (120000) exit was called at
D:/InterfaceServer/Perl/lib/CGI/Carp.pm line 561
Parent: child process exited with status 255 -- Restarting.

We are going in the right direction, just need to figure out how to solve
this new issue.

Does anyone have any ideas on how to fix this?

Thanks, as always.

Hans

On Wed, Feb 9, 2011 at 10:22 PM, Randolf Richardson wrote:

> > Awesome everyone. Thanks for working on the new release of mod_perl. I
> look
> > forward to implementing it.
>
> This is great news! I'm very pleased to see this update because it
> flies in the face of those who incorrectly insist that ModPerl is
> dead because it hasn't been updated for a long time -- I've been
> pointing out that the lack of updates are due to better quality code
> and fewer change requirements.
>
> Thanks too all developers and contributors of ModPerl! I've been
> hooked on this technology ever since I started using it, and I enjoy
> the high performance and deep integration into APR and HTTPd.
>
> > Has anyone tried 2.0.5 on Windows?
>
> I haven't yet, but I look forward to trying it on NetBSD 5.1. I am
> interested in trying it on Windows when a binary is available...
>
> I find that running ModPerl on Windows generally works well until
> Perl scripts are changed frequently (and using the Reload module),
> and then Apache HTTPd will either stop responding or just crash out
> (especially if PerlMagick is in the mix). I wonder if this might be
> an OS-specific problem thought since my Unix servers just don't
> exhibit these symptoms.
>
> [End of reply.]
>
> > On Wed, Feb 9, 2011 at 6:12 PM, Jie wrote:
> >
> > > Thank you so much for the new release!
> > >
> > > Jie
> > >
> > > Please think of our environment and only print this e-mail if
> necessary.
> > >
> > > * Andr? Warnier wrote:
> > >
> > > > Date: Tue, 08 Feb 2011 09:18:33 +0100
> > > > From: Andr? Warnier
> > > > To: mod_perl Dev
> > > > CC: mod_perl list
> > > > Subject: Re: [ANNOUNCE] mod_perl 2.0.5
> > > > User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
> > > >
> > > > Many thanks guys, for keeping mod_perl alive and well (and perl too
> for
> > > that matter).
> > > > It is really a pity that not more people know how much their nice
> > > > web applications depend on it.
> > > > But then, maybe we should think that the people who matter, do know.
> > > >
> > >
> >
>
>
> Randolf Richardson - randolf@inter-corporate.com
> Inter-Corporate Computer & Network Services, Inc.
> Vancouver, British Columbia, Canada
> http://www.inter-corporate.com
>
>
>

--90e6ba4fc18cb6550204a4660fe7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I have finally started testing mod_perl-2.0.5 on windows (both win 2003 / 2=
008).

Re: [ANNOUNCE] mod_perl 2.0.5

Hans,

> ModPerl::Util::exit: (120000) exit was called at
> D:/InterfaceServer/Perl/lib/CGI/Carp.pm line 561
> Parent: child process exited with status 255 -- Restarting.

I have done a lot of testing on windows with the 2.05 release and have not
seen this error before. It must be something specific in your code. It
looks like the exit command is triggers some where in your code (
http://perl.apache.org/docs/2.0/api/ModPerl/Util.html#C_exit _ ).

Does it also restart Apache?

I have done some testing with calling ModPerl::Util::exit(0) (that's what
is actually done in CGI::Carp) and did not found an error in my log. does
it say [error] or [warn] in your log file ?

--
Thomas

Re: [ANNOUNCE] mod_perl 2.0.5

--bcaec548a3618abe8804a46f9404
Content-Type: text/plain; charset=UTF-8

Yes, the entire process restarts.

Here is the exact line:

ModPerl::Util::exit: (120000) exit was called at
D:/InterfaceServer/Perl/lib/CGI/Carp.pm line 561
[Sun May 29 05:25:10 2011] [notice] Parent: child process exited with status
255 -- Restarting.

It's a notice.

I did some further testing and found that it restarts and exits apache when
the application is printing to the browser. So, if you have a bunch of data
to send to the browser and the connection stops in the middle, it throws
the above error.

my $template = "Lots of data ..";
print $template;

Is there a better way to transfer lots of data to the browser?

This is where I was able to to track it down to. If I stop the browser
before it hits this print line, the "ModPerl::Util::exit(0)" works.

Thanks fro taking a look.

Hans

On Sun, May 29, 2011 at 3:07 PM, Thomas den Braber wrote:

> Hans,
>
> > ModPerl::Util::exit: (120000) exit was called at
> > D:/InterfaceServer/Perl/lib/CGI/Carp.pm line 561
> > Parent: child process exited with status 255 -- Restarting.
>
> I have done a lot of testing on windows with the 2.05 release and have not
> seen this error before. It must be something specific in your code. It
> looks like the exit command is triggers some where in your code (
> http://perl.apache.org/docs/2.0/api/ModPerl/Util.html#C_exit _ ).
>
> Does it also restart Apache?
>
> I have done some testing with calling ModPerl::Util::exit(0) (that's what
> is actually done in CGI::Carp) and did not found an error in my log. does
> it say [error] or [warn] in your log file ?
>
> --
> Thomas
>
>
>

--bcaec548a3618abe8804a46f9404
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Yes, the entire process restarts.

Re: [ANNOUNCE] mod_perl 2.0.5

You might try pulling and building from svn trunk, Steve Hay fixed
something that may be related. I don't have enough WinFoo to say for
sure. Or wait another 4-6 weeks for 2.0.6.

http://perl.apache.org/download/source.html

=3Ditem 2.0.6-dev

PerlIOApache_flush() and mpxs_Apache2__RequestRec_rflush() now no longer th=
row
exceptions when modperl_wbucket_flush() fails if the failure was just a res=
et
connection or an aborted connection. The failure is simply logged to the er=
ror
log instead. This should fix cases of httpd.exe crashing when users press t=
he
Stop button in their web browsers.
[Steve Hay]

On Sun, May 29, 2011 at 7:56 PM, Hans Scharler wrote:
> Yes, the entire process restarts.
> Here is the exact line:
> ModPerl::Util::exit: (120000) exit was called at
> D:/InterfaceServer/Perl/lib/CGI/Carp.pm line 561
> [Sun May 29 05:25:10 2011] [notice] Parent: child process exited with sta=
tus
> 255 -- Restarting.
> It's a notice.
> I did some further testing and found that it restarts and exits apache wh=
en
> the application is printing to the browser. So, if you have a bunch of da=
ta
> to send to the browser and the connection stops in the middle, it throws
> the=A0above=A0error.
> my $template =3D "Lots of data ..";
> print $template;
> Is there a better way to transfer lots of data to the browser?
> This is where I was able to to track it down to. If I stop the browser
> before it hits this print line, the "ModPerl::Util::exit(0)" works.
> Thanks fro taking a look.
> Hans
>
> On Sun, May 29, 2011 at 3:07 PM, Thomas den Braber wrot=
e:
>>
>> Hans,
>>
>> > ModPerl::Util::exit: (120000) exit was called at
>> > D:/InterfaceServer/Perl/lib/CGI/Carp.pm line 561
>> > Parent: child process exited with status 255 -- Restarting.
>>
>> I have done a lot of testing on windows with the 2.05 release and have n=
ot
>> seen this error before. It must be something specific in your code. It
>> looks like the exit command is triggers some where in your code (
>> http://perl.apache.org/docs/2.0/api/ModPerl/Util.html#C_exit _ ).
>>
>> Does it also restart Apache?
>>
>> I have done some testing with calling ModPerl::Util::exit(0) (that's wha=
t
>> is actually done in CGI::Carp) and did not found an error in my log. doe=
s
>> it say [error] or [warn] in your log file ?
>>
>> --
>> Thomas
>>
>>
>
>

Re: [ANNOUNCE] mod_perl 2.0.5

--bcaec54ee6dec604fb04ab361c43
Content-Type: text/plain; charset=UTF-8

Any word on the release of mod_perl 2.0.6?

I will be glad to test to see if it solves the Apache restart issue when a
client stops the browser.

Thanks,
Hans


On Mon, May 30, 2011 at 8:31 PM, Fred Moyer wrote:

> You might try pulling and building from svn trunk, Steve Hay fixed
> something that may be related. I don't have enough WinFoo to say for
> sure. Or wait another 4-6 weeks for 2.0.6.
>
> http://perl.apache.org/download/source.html
>
> =item 2.0.6-dev
>
> PerlIOApache_flush() and mpxs_Apache2__RequestRec_rflush() now no longer
> throw
> exceptions when modperl_wbucket_flush() fails if the failure was just a
> reset
> connection or an aborted connection. The failure is simply logged to the
> error
> log instead. This should fix cases of httpd.exe crashing when users press
> the
> Stop button in their web browsers.
> [Steve Hay]
>
> On Sun, May 29, 2011 at 7:56 PM, Hans Scharler
> wrote:
> > Yes, the entire process restarts.
> > Here is the exact line:
> > ModPerl::Util::exit: (120000) exit was called at
> > D:/InterfaceServer/Perl/lib/CGI/Carp.pm line 561
> > [Sun May 29 05:25:10 2011] [notice] Parent: child process exited with
> status
> > 255 -- Restarting.
> > It's a notice.
> > I did some further testing and found that it restarts and exits apache
> when
> > the application is printing to the browser. So, if you have a bunch of
> data
> > to send to the browser and the connection stops in the middle, it throws
> > the above error.
> > my $template = "Lots of data ..";
> > print $template;
> > Is there a better way to transfer lots of data to the browser?
> > This is where I was able to to track it down to. If I stop the browser
> > before it hits this print line, the "ModPerl::Util::exit(0)" works.
> > Thanks fro taking a look.
> > Hans
> >
> > On Sun, May 29, 2011 at 3:07 PM, Thomas den Braber
> wrote:
> >>
> >> Hans,
> >>
> >> > ModPerl::Util::exit: (120000) exit was called at
> >> > D:/InterfaceServer/Perl/lib/CGI/Carp.pm line 561
> >> > Parent: child process exited with status 255 -- Restarting.
> >>
> >> I have done a lot of testing on windows with the 2.05 release and have
> not
> >> seen this error before. It must be something specific in your code. It
> >> looks like the exit command is triggers some where in your code (
> >> http://perl.apache.org/docs/2.0/api/ModPerl/Util.html#C_exit _ ).
> >>
> >> Does it also restart Apache?
> >>
> >> I have done some testing with calling ModPerl::Util::exit(0) (that's
> what
> >> is actually done in CGI::Carp) and did not found an error in my log.
> does
> >> it say [error] or [warn] in your log file ?
> >>
> >> --
> >> Thomas
> >>
> >>
> >
> >
>

--bcaec54ee6dec604fb04ab361c43
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Any word on the release of mod_perl 2.0.6?

Re: [ANNOUNCE] mod_perl 2.0.5

The word is 'pretty soon'. We're working out some of the release
issues that slowed down the last release.

You can always pull from subversion trunk and test with that version
to see if it resolves the issue you are seeing.

On Tue, Aug 23, 2011 at 6:19 PM, Hans Scharler wrote:
> Any word on the release of mod_perl 2.0.6?
> I will be glad to test to see if it solves the Apache restart issue when =
a
> client stops the browser.
> Thanks,
> Hans
>
> On Mon, May 30, 2011 at 8:31 PM, Fred Moyer wrot=
e:
>>
>> You might try pulling and building from svn trunk, Steve Hay fixed
>> something that may be related. =A0I don't have enough WinFoo to say for
>> sure. =A0Or wait another 4-6 weeks for 2.0.6.
>>
>> http://perl.apache.org/download/source.html
>>
>> =3Ditem 2.0.6-dev
>>
>> PerlIOApache_flush() and mpxs_Apache2__RequestRec_rflush() now no longer
>> throw
>> exceptions when modperl_wbucket_flush() fails if the failure was just a
>> reset
>> connection or an aborted connection. The failure is simply logged to the
>> error
>> log instead. This should fix cases of httpd.exe crashing when users pres=
s
>> the
>> Stop button in their web browsers.
>> [Steve Hay]
>>
>> On Sun, May 29, 2011 at 7:56 PM, Hans Scharler
>> wrote:
>> > Yes, the entire process restarts.
>> > Here is the exact line:
>> > ModPerl::Util::exit: (120000) exit was called at
>> > D:/InterfaceServer/Perl/lib/CGI/Carp.pm line 561
>> > [Sun May 29 05:25:10 2011] [notice] Parent: child process exited with
>> > status
>> > 255 -- Restarting.
>> > It's a notice.
>> > I did some further testing and found that it restarts and exits apache
>> > when
>> > the application is printing to the browser. So, if you have a bunch of
>> > data
>> > to send to the browser and the connection stops in the middle, it thro=
ws
>> > the=A0above=A0error.
>> > my $template =3D "Lots of data ..";
>> > print $template;
>> > Is there a better way to transfer lots of data to the browser?
>> > This is where I was able to to track it down to. If I stop the browser
>> > before it hits this print line, the "ModPerl::Util::exit(0)" works.
>> > Thanks fro taking a look.
>> > Hans
>> >
>> > On Sun, May 29, 2011 at 3:07 PM, Thomas den Braber
>> > wrote:
>> >>
>> >> Hans,
>> >>
>> >> > ModPerl::Util::exit: (120000) exit was called at
>> >> > D:/InterfaceServer/Perl/lib/CGI/Carp.pm line 561
>> >> > Parent: child process exited with status 255 -- Restarting.
>> >>
>> >> I have done a lot of testing on windows with the 2.05 release and hav=
e
>> >> not
>> >> seen this error before. It must be something specific in your code. I=
t
>> >> looks like the exit command is triggers some where in your code (
>> >> http://perl.apache.org/docs/2.0/api/ModPerl/Util.html#C_exit _ ).
>> >>
>> >> Does it also restart Apache?
>> >>
>> >> I have done some testing with calling ModPerl::Util::exit(0) (that's
>> >> what
>> >> is actually done in CGI::Carp) and did not found an error in my log.
>> >> does
>> >> it say [error] or [warn] in your log file ?
>> >>
>> >> --
>> >> Thomas
>> >>
>> >>
>> >
>> >
>
>